System and method for antivirus checking of files based on level of trust of their digital certificates

ABSTRACT

Disclosed are systems, methods and computer program products for antivirus checking of files based on level of trust of their digital certificates. An example method includes obtaining a digital certificate of a digital signature of a file; determining validity of the obtained digital certificate; assigning a level of trust to the digital certificate based on the determined validity or invalidity of the digital certificate of the file; based on the assigned level of trust of the digital certificate of the file, determining what antivirus checking method to perform on the file; and performing the determined antivirus checking method on the file.

FIELD OF TECHNOLOGY

The disclosure relates generally to the field of computer security andin particular to antivirus checking of files based on level of trust oftheir digital certificates.

BACKGROUND

The popularity of computer and network technologies has been rapidlygrowing for the past two decades; however, it has been accompanied by asteady growth in cybercrime, which ranges from relatively harmlesscases, such as distribution of unsolicited e-mail, commonly known asspam, to more serious cases of cybercrimes, such as denial of serviceattacks, stealing of confidential financial information, and even cyberwarfare and terrorism. It has become obvious that it is imperative toaggressively combat cybercrime. And, one of the most commonly used meansfor protecting computers from cyber attacks is antivirus software.However, current generation of antivirus software solutions hasshortcomings.

Typical antivirus applications can perform several different malwaredetection methods, generally ranging from relatively quick signaturematching to more complex heuristic analysis and emulation. The latterantivirus checking methods are generally resource intensive, which hasdetrimental effect on the productivity of computers on which they arerun, especially during performance of frequent and complex antiviraltasks. Examples of such tasks are checking hard disk for malware, whichsignificantly loads computer's disk system. The consumption ofprocessing resources by antivirus application especially affectspersonal computers, notebooks and other types of computers that havelimited processing capabilities.

Accordingly, there is a need to improve efficiency of operation ofantivirus software.

SUMMARY

Disclosed are systems, methods and computer program products forantivirus checking of files based on level of trust of their digitalcertificates. In one aspect, an example method for performing antiviruschecking of a file comprises: obtaining a digital certificate of adigital signature of the file; determining, by a hardware processor,validity of the obtained digital certificate; assigning a level of trustto the digital certificate based on the determined validity orinvalidity of the digital certificate of the file; based on the assignedlevel of trust of the digital certificate of the file, determining whatantivirus checking method to perform on the file; and performing thedetermined antivirus checking method on the file.

In one example aspect, the method may further comprise: assigning a lowlevel of trust to an invalid digital certificate or digital certificateof a known malicious file; and performing one or more of heuristicanalysis, emulation, manual checking and blocking of execution of thefile having a digital certificated with a low level of trust.

In one example aspect, the method may further comprise: assigning amedium level of trust to valid digital certificate; and performingsignature matching of the file having a digital certificated with amedium level of trust.

In one example aspect, the method may further comprise: assigning a highlevel of trust to digital certificates issued by a trusted certificationauthority; and not performing antivirus checking of a file having adigital certificate with a high level of trust.

In one example aspect, determining validity of the digital certificatemay includes: constructing a certificate chain associated with thecertificate of the file; and traversing the certificate chain andvalidating each certificate in the chain.

In one example aspect, the method may further comprise assigning a lowlevel of trust to an intermediate certificate in the certificate chainthat were found in the certificate chains of a malicious file.

In one example aspect determining whether a digital certificate is validwhen one or more of the following conditions is met: the digitalsignature of the certification authority is correct; the validity periodof the certificate has not expired at the present moment; and thecertificate has not been revoked.

In another aspect, an example system for performing antivirus checkingof a file, the system comprising: a hardware processor configured toobtain a digital certificate of a digital signature of the file;determine validity of the obtained digital certificate of the file;assign a level of trust to the digital certificate based on thedetermined validity or invalidity of the digital certificate of thefile; based on the assigned level of trust of the digital certificate ofthe file, determine what antivirus checking method to perform on thefile; and perform the determined antivirus checking method on the file.

In another aspect, an example computer program product, stored on anon-transitory computer readable medium, includes computer executableinstructions for performing antivirus checking of a file, includinginstructions for: obtaining a digital certificate of a digital signatureof the file; determining, by a hardware processor, validity of theobtained digital certificate; assigning a level of trust to the digitalcertificate based on the determined validity or invalidity of thedigital certificate of the file; based on the assigned level of trust ofthe digital certificate of the file, determining what antivirus checkingmethod to perform on the file; and performing the determined antiviruschecking method on the file.

The above simplified summary of example aspects serves to provide abasic understanding of the present disclosure. This summary is not anextensive overview of all contemplated aspects, and is intended toneither identify key or critical elements of all aspects nor delineatethe scope of any or all aspects of the present disclosure. Its solepurpose is to present one or more aspects in a simplified form as aprelude to the more detailed description of the disclosure that follows.To the accomplishment of the foregoing, the one or more aspects of thepresent disclosure include the features described and particularlypointed out in the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated into and constitute apart of this specification, illustrate one or more example aspects ofthe present disclosure and, together with the detailed description,serve to explain their principles and implementations.

FIG. 1 shows an example system for antivirus checking of files based onlevel of trust of their digital certificates according to one exampleaspect.

FIG. 2 shows an example method of populating the database of trustedcertificates according to one example aspect.

FIG. 3 shows an example method of antivirus checking of a file based onthe level of trust of its digital certificate according to one exampleaspect.

FIG. 4 shows an example method of traversing and validating thecertificate chain according to one example aspect.

FIG. 5 shows an example diagram of traversing and validating thecertificate chain according to one example aspect.

FIG. 6 shows an example of a general-purposes computer system, such as apersonal computer or a server, suitable for implementing the disclosedaspects of systems and method for antivirus checking of files based onlevel of trust of their digital certificates according to one aspect.

DETAILED DESCRIPTION

Example aspects are described herein in the context of a system, methodand computer program product for antivirus checking of files based onlevel of trust of their digital certificates. Those of ordinary skill inthe art will realize that the following description is illustrative onlyand is not intended to be in any way limiting. Other aspects willreadily suggest themselves to those skilled in the art having thebenefit of this disclosure. Reference will now be made in detail toimplementations of the example aspects as illustrated in theaccompanying drawings. The same reference indicators will be used to theextent possible throughout the drawings and the following description torefer to the same or like items.

FIG. 1 shows a general diagram of an example system for antiviruschecking of files based on level of trust of their digital certificatesaccording to one aspect. The term digital certificate also commonlyreferred to as a public key certificate or an identify certificate. Thesystem 100 includes a user computer 110 with installed application 101.The computer 110 can be, for example, a personal computer (PC), anotebook, a tablet, a smartphone, or other type of computing device. Inone example aspect, the application 101 may be an antivirus programconfigured to perform antivirus checking of files 102 stored ordownloaded on the computer 110 using, for example, signature matching,emulation, heuristic analysis and other known malware detectiontechniques. In one example aspect, the antivirus application 101 mayalso check the validity of the public key certificate of the files'digital signatures. The certificate may be deemed valid if one or moreof the following conditions are met:

-   -   the digital signature of the certification authority (CA)s        correct;    -   the validity period of the certificate has not expired at the        present moment; and    -   the certificate has not been revoked.

In one example aspect, the system 100 may also include a server 120,which is connected via a private or public network to the user computer110. The server 120 includes a verification module 103, connected to theapplication 101, and designed to obtain an end certificate from theapplication 101 upon performing a verification of the certificate. Theend certificate may be the public key certificate of the softwaremanufacturer whose digital signature was used to sign the file 102. Amodule of assigning a level of trust 104 is connected to theverification module 103 and serves to determine the level of trust forcertificates with the help of a database of trusted certificates 105.The level of trust as used herein refers to a parameter (such as aninteger) determining the validity of the certificate, and it is used forthe antivirus checking of file 102. The database 105 is connected to themodule of assigning the level of trust 104, and it containscertificates, as well as their corresponding levels of trust andidentifiers which can be used to uniquely determine each certificate.The certificate identifier can be, for example, a serial number, apublic key, a thumbprint (the hash sum from the public key of thecertificate), the issuer and subject names, and so on.

In one example aspect, the user computer 110 may also includes a localdatabase of trusted certificates 105 a, which is connected the serverdatabase 105. The local database 105 a may contain a complete or partiallist of certificates with corresponding levels of trust. The localdatabase 105 a may be periodically updated with information from thedatabase 105.

In one example aspect, the module of assigning the level of trust 104 isconfigured to populate the database 105 with the certificates of files102 and appropriate levels of trust to the certificates. In one exampleaspect, the level of trust of a digital certificate can take on thefollowing values: low, medium and high. A low level of trust mayindicate that the digital signature of the subject of the certificate isinvalid. For example, a low level of trust may be assigned tocertificates of the digital signature used to sign malicious files. Alist of malicious files and their certificates may be obtained from thedatabase of malicious files 106. Files whose certificates have low levelof trust might require additional antivirus checking by the application101. Additional checking may for example include antivirus analysisusing more complex and resource-intensive malware detection techniques,such as emulation and heuristic analysis, as compared to the routineantivirus check using signature matching. In one example aspect,additional checking may include manually analysis of the file by humansoftware experts. A medium level of trust may be assigned to validcertificates whose identifiers have been received from the users. Amedium level of trust may indicate that a routine antivirus check by theantivirus application 101, such as signature matching, may besufficient. A high level of trust may be assigned to certificates whosecertification authority is contained on the list of trustedcertification authorities. For example, the trusted certificationauthorities can be the CAs of the largest software producers. In anotherexample, the list of trusted certification authorities can be stored onthe server 120. A high level of trust may indicate that the file is safeand no additional antivirus checks are needed on these files.

In one example aspect, the verification module 103 is configured to formthe certificate chain from the end certificate to the root certificate.The certificate chain consists of the set of certificates needed tocertify the software producer identified by the end certificate. Usuallythe certificate chain contains an end certificate, a set of intermediatecertificates, and a root certificate—the certificate of a rootcertification authority trusted by all parties in the certificate chain.Each intermediate CA in the chain contains a certificate issued by acertification authority on a higher level in the chain. The root CAissues a certificate for itself. Furthermore, the verification module103 serves to determine one of:

-   -   a first certificate of the certificate chain that is contained        in the database 105;    -   an end certificate in the certificate chain.

In one example aspect, the server 120 may also include a database ofmalicious files 106 that contains, for each known malicious file, itshash sum, the public key certificate of the digital signature and itsidentifier, the status of the malicious file (for example, virus, rootkit, worm, Trojan horse), the initial file, and other type ofinformation that may be used for file identification.

In one example aspect, the application 101 and the file 102 may belocated on the user computer 110, while the modules 103-106 may belocated on the server 120. In another example aspect, the database 105can be located on the user computer 110.

FIG. 2 shows an example method of populating the database of trustedcertificates according to one example aspect. When an unknown file 102is executed on the computer 110, the application 101 may send anidentifier of the certificate and the file (e.g., the hash sum of thefile) to the server 120 for validation. Since the application 101 may beinstalled on a group of computers of different users, the server 120 mayreceive identifiers of certificates for many unknown files 102 from usercomputers 110. The verification module 103 may use the receivedidentifiers to verify using the database 105 validity of the associatedcertificates. If a certificate for the received identifier was not foundin the database 105, the verification module 103 can request the unknownfile 102 from the application 101. Alternatively, the verificationmodule 103 can obtain the unknown file 102 directly from the softwareproducer.

In one example aspect, the verification module 103 may periodically(e.g., once a day) arranges the certificates in terms of the number ofusers from which the identifier of the corresponding certificate wasobtained. In step 210, the verification module 103 may select from thearranged list of certificates a certain number of the most popularcertificates for example, the first ten certificates). In anotherexample aspect, the verification module 103 may check all thecertificates whose identifiers have been received from users.

In step 220, the verification module 103 may check validity of theselected certificates. A certificate may be found valid when one or moreof the following conditions is met:

-   -   the digital signature of the certification authority is correct;    -   the validity period of the certificate has not expired at the        present moment;    -   the certificate has not been revoked.

Furthermore, a certificate may be found invalid for the followingreasons:

-   -   the validity period has expired for one of the certificates in        the certificate chain;    -   the validity periods of the certificates in the certificate        chain might not overlap;    -   the certificate chain is circular (i.e., one of the certificates        of the certificate chain was issued by a CA that was certified        by the CA of the certificate being checked).

It should be noted that the checking of the validity of the certificateis not limited to the above given conditions, but can also include otherconditions, such as those identified in ITU-T standard for a public keyinfrastructure (PKI) X.509.

In one example aspect, the checking of the digital signature can be doneby system resources (e.g., in Windows OS by the Sign Tool program). Inone example aspect, the checking of the digital signature can be done bydeciphering it with the public key contained in the public keycertificate of the given digital signature and then comparing theresulting value of the hash function of the file with the calculatedvalue of the hash function of the file.

In one example aspect, in step 230, the module of assigning the level oftrust 104 may assign different levels of trust to the certificates ofunknown files received from user computers 110. For example, a mediumlevel of trust may be assigned to valid certificates whose identifiershave been received from the users. In step 240, a low level of trust maybe assigned to the remaining invalid certificates whose identifiers havebeen received from the users. For example, a low level of trust may beassigned to certificates of the digital signature used to sign maliciousfiles. A list of malicious files and their certificates may be obtainedfrom the database of malicious files 106. In step 250, a high level oftrust may be assigned to certificates whose certification authority iscontained on the list of trusted certification authorities. In oneexample aspect, the trusted certification authorities can be the CAs ofthe largest software producers. In another example aspect, the list oftrusted certification authorities can be previously drawn up by theserver 120.

In one example aspect, in step 240, a low level of trust can be assignedto intermediate certificates which are found in the certificate chainsin a certain set of malicious files. For example, if an intermediatecertificate was present in ten certificate chains, whereby six filessigned by the end certificates of these chains were malicious, a lowlevel of trust will be assigned to this particular intermediatecertificate. At the same time, if it turns out that there were twomalicious files, for example, the intermediate certificate may beassigned a medium level of trust, since there is insufficient basis tosuppose that the intermediate certificate has been discredited.

As a result, in step 260, the module of assigning the level of trust 104adds to (if the database 105 was only just created and is thereforeempty) or updates the database 105 with the certificates of the obtainedfiles 102 and their corresponding levels of trust.

FIG. 3 shows an example method of antivirus checking of a file usinginformation about the level of trust of its digital certificateaccording to one example aspect. In the first step 310, the verificationmodule 103 receives the identifier of the end certificate of the publickey of the digital signature of a file which is being checked by theapplication 101. Next, in step 320, the verification module 103constructs the certificate chain from the end certificate to the rootcertificate. Using the database 105, the certificate can be uniquelydefined from its identifier. The construction of the certificate chainis done using method known to those of ordinary skill in the art ofcomputer security. For example, for the end certificate, the first CAwhich issued the certificate is determined. For the certificate of thefirst CA, the second CA having issued the certificate of the first CA isdetermined, and so on, until the root CA is determined.

In step 330, the verification module 103 successively traverses thecertificate chain, performing in succession a search for eachcertificate of the chain in the database 105. The level of trust of theend certificate will be renewed according to the result of validation ofall certificates in the chain. The method of traversing and validatingthe certificate chain will be discussed in a great detail herein belowwith reference to FIG. 4.

As a result, in step 340 the level of trust for the end certificate isdetermined using the database 105. Finally, in step 350, the application101 on the computer 110 determines whether to perform an antivirus checkfor the file 102 and what method of antivirus check to perform based onthe level of trust of the end certificate of the file 102. Thisdependency is dictated by the rules of verification, which will bedescribed herein below in Table 1. In one example aspect, the method ofantivirus checking may depend on the content of the fields of thedigital certificate, such as; validity period, certificate-issuingcountry, etc.

FIG. 4 shows an example method of traversing and validating thecertificate chain according to one example aspect. The checking of thecertificates may be done sequentially, starting from the end certificateand finishing with the root certificate. In step 410, a check is made asto whether the end certificate is contained in the database 105. If thecertificate is found in the database 105, no further traversing of thecertificate chain is required. Otherwise, in step 420, the traversing ofthe certificate chain is continued starting from the next certificate inthe chain and until it is determined, in step 430, that the particularintermediate certificate is contained in the database 105 with a lowlevel of trust (step 430), or until the root certificate is reached(steps 440). If an intermediate certificate is contained in the database105 with a high or medium level of trust, the traversal the chain willcontinue.

If an intermediate certificate is contained in the database 105 and ithas a low level of trust, the end certificate will likewise be assigneda low level of trust. This step lets one determine a malicious file whenone of the intermediate certificates of the certificate chain has a lowlevel of trust, even if for some reason (for example, the intermediatecertificate was revoked due to compromising of the CA, while the parentCAs have not been compromised) the other certificates of the certificatechain have a medium or high level of trust.

If the root certificate has been reached and at least one of theintermediate certificates is contained in the database 105 with a mediumor high level of trust, the end certificate of the file may be assigneda medium level of trust according to one example aspect.

Furthermore, in step 440, a check may be made to determine whetherintermediate certificates with a high level of trust were present in thecertificate chain. If so, the end certificate will also be assigned ahigh level of trust.

The last possible result of traversing and validating the certificatechain is: none of the certificates of the chain is contained in thedatabase 105. In this case, the end certificate may be assigned a lowlevel of trust. Moreover, in one example aspect, the identifier of theend certificate may be sent to the verification module 103, which willanalyze the certificate in accordance with the method presented in FIG.2. In another example aspect, the identifier of the file (such as thehash sum) can also be send to the verification module 103.

An example of the rules of verification for an antivirus check aftercompleting the traversal of the certificate chain is presented in table1 below.

TABLE 1 Level of trust of No end certificate Rule 1 High File is deemedtrusted, no further antivirus check not needed 2 Medium Additionalantivirus check needed 3 Low More thorough additional antivirus check ofthe file needed (automated or manual)

For example, according to the first rule if a certificate has been foundby the method presented in FIG. 4 which is an end certificate with ahigh level of trust, the file is deemed legitimate and no furtherantivirus check may be necessary. But according to the second rule, afurther antivirus check will be performed. Such a check might be, forexample, heuristic analysis, the use of cloud services, emulation, orother complex, resource-intensive methods.

According to the third rule of table 1, an additional antivirus checkwill be performed if the file was not digitally signed or the digitalsignature is incorrect. In this case, the most careful antivirus checkor a complex of checks able to find malicious files with greaterprobability will be performed. For example, more resource-intensiveheuristic analysis, behavioral algorithms, etc. may be used. In oneexample aspect, if the certificate has a low level of trust, theapplication 101 may block execution of the corresponding file.

FIG. 5 shows one example of traversing and validating a certificatechain according to the method presented in FIG. 4. In this example, afile has been signed by the end certificate 501. The certificate chainconsists of certificates 501-506. That is, the end certificate 501 wassigned by the CA 4, whose certificate 502 was signed by CA 3, and so on.

The verification module 103, in step 410, sequentially traverses thecertificates of the certificate chain, starting with the rootcertificate. The first certificate which is present in the database 105is certificate 502, which has a high level of trust according to thedatabase 105. Since it is not the root certificate, according to themethod presented in FIG. 4 the traversing of the certificate chain willcontinue (step 440). The certificate 503 is not contained in thedatabase 105. The next certificate 504 is contained in the database witha low level of trust. Even though two unchecked certificates stillremain in the certificate chain, there is no need to continue traversingthe certificate chain (step 450), since a discredited intermediatecertificate 504 has been found. According to rule 3 of table 1, the mostthorough additional antivirus checking of the file should be performed.

FIG. 6 shows an example of a general-purpose computer system (which maybe a personal computer or a server) 20, which may be used to implementsystem and methods for antivirus checking of files based on level oftrust of their digital certificates disclosed herein. The computersystem 20 includes a central processing unit 21, a system memory 22 anda system bus 23 connecting the various system components, including thememory associated with the central processing unit 21. The system bus 23is realized like any bus structure known from the prior art, includingin turn a bus memory or bus memory controller, a peripheral bus and alocal bus, which is able to interact with any other bus architecture.The system memory includes permanent memory (ROM) 24 and random-accessmemory (RAM) 25. The basic input/output system (BIOS) 26 includes thebasic procedures ensuring the transfer of information between elementsof the computer 20, such as those at the time of loading the operatingsystem with the use of the ROM 24.

The computer 20, in turn, includes a hard disk 27 for reading andwriting of data, a magnetic disk drive 28 for reading and writing onremovable magnetic disks 29 and an optical drive 30 for reading andwriting on removable optical disks 31, such as CD-ROM, DVD-ROM and otheroptical information media. The hard disk 27, the magnetic disk drive 28,and the optical drive 30 are connected to the system bus 23 across thehard disk interface 32, the magnetic disk interface 33 and the opticaldrive interface 34, respectively. The drives and the correspondingcomputer information media are power-independent modules for storage ofcomputer instructions, data structures, program modules and other dataof the computer 20.

The computer 20 may include one or more hard disk drives 27, removablemagnetic disks 29 and removable optical disks 31, but it should beunderstood that it is possible to employ other types of computerinformation media 56 which are able to store data in a form readable bya computer (solid state drives, flash memory cards, digital disks,random-access memory (RAM) and so on), which are connected to the systembus 23 via the controller 55.

The computer 20 has a file system 36, where the recorded operatingsystem 35 is stored, and also additional program applications 37, otherprogram modules 38 and program data 39. The user is able to entercommands and information into the computer 20 by using input devices(keyboard 40, mouse 42). Other input devices (not shown) can be used;microphone, joystick, game controller, scanner, and so on. Such inputdevices usually plug into the computer system 20 through a serial port46, which in turn is connected to the system bus, but they can beconnected in other ways, for example, with the aid of a parallel port, agame port or a universal serial bus (USB). A monitor 47 or other type ofdisplay device is also connected to the system bus 23 across aninterface, such as a video adapter 48. In addition to the monitor 47,the personal computer can be equipped with other peripheral outputdevices (not shown), such as loudspeakers, a printer, and so on.

The computer 20 is able to work in a network environment, using anetwork connection to one or more remote computers 49. The remotecomputer (or computers) 49 may also be personal computers or servershaving the majority or all of the aforementioned elements in describingthe nature of the computer 20. Other devices can also be present in thecomputer network, such as routers, network stations, peer devices orother network nodes.

Network connections can form a local-area computer network (LAN) 50 anda wide-area computer network (WAN). Such networks are used in corporatecomputer networks and internal company networks, and they generally haveaccess to the Internet. In LAN or WAN networks, the computer 20 isconnected to the local-area network 50 across a network adapter ornetwork interface 51. When networks are used, the computer 20 can employa modem 54 or other modules for providing communications with awide-area computer network such as the Internet. The modem 54, which isan internal or external device, is connected to the system bus 23 by aserial port 46. It should be noted that the network connections are onlyexamples and need not depict the exact configuration of the network,i.e., in reality there are other ways of establishing a connection ofone computer to another by technical communication modules.

In various aspects, the systems and methods described herein may beimplemented in hardware, software, firmware, or any combination thereof.If implemented in software, the methods may be stored as one or moreinstructions or code on a non-transitory computer-readable medium.Computer-readable medium includes data storage. By way of example, andnot limitation, such computer-readable medium can comprise RAM, ROM,EEPROM, CD-ROM, Flash memory or other types of electric, magnetic, oroptical storage medium, or any other medium that can be used to carry orstore desired program code in the form of instructions or datastructures and that can be accessed by a processor of a general purposecomputer.

In various aspects, the systems and methods described in the presentdisclosure in terms of modules. The term “module” as used herein refersto a real-world device, component, or arrangement of componentsimplemented using hardware, such as by an application specificintegrated circuit (ASIC) or field-programmable gate array (FPGA), forexample, or as a combination of hardware and software, such as by amicroprocessor system and a set of instructions to implement themodule's functionality, which (while being executed) transform themicroprocessor system into a special-purpose device. A module can alsobe implemented as a combination of the two, with certain functionsfacilitated by hardware alone, and other functions facilitated by acombination of hardware and software. In certain implementations, atleast a portion, and in some cases, all, of a module can be executed onthe processor of a general purpose computer (such as the one describedin greater detail in FIG. 3 above). Accordingly, each module can berealized in a variety of suitable configurations, and should not belimited to any particular implementation exemplified herein.

In the interest of clarity, not all of the routine features of theaspects are disclosed herein. It will be appreciated that in thedevelopment of any actual implementation of the present disclosure,numerous implementation-specific decisions must be made in order toachieve the developer's specific goals, and that these specific goalswill vary for different implementations and different developers. Itwill be appreciated that such a development effort might be complex andtime-consuming, but would nevertheless be a routine undertaking ofengineering for those of ordinary skill in the art having the benefit ofthis disclosure.

Furthermore, it is to be understood that the phraseology or terminologyused herein is for the purpose of description and not of restriction,such that the terminology or phraseology of the present specification isto be interpreted by the skilled in the art in light of the teachingsand guidance presented herein, in combination with the knowledge of theskilled in the relevant art(s). Moreover, it is not intended for anyterm in the specification or claims to be ascribed an uncommon orspecial meaning unless explicitly set forth as such.

The various aspects disclosed herein encompass present and future knownequivalents to the known modules referred to herein by way ofillustration. Moreover, while aspects and applications have been shownand described, it would be apparent to those skilled in the art havingthe benefit of this disclosure that many more modifications thanmentioned above are possible without departing from the inventiveconcepts disclosed herein.

The invention claimed is:
 1. A method for performing antivirus checking of a file, the method comprising: obtaining a digital certificate of the file, wherein the digital certificate is an end certificate associated with a certificate chain; determining, by a hardware processor, validity of the obtained digital certificate by decrypting a digital signature of the obtained digital certificate using a public key of an intermediate certificate authority, calculating a hash value of the digital certificate, and determining a match of the decrypted digital signature with the calculated hash value; assigning a level of trust to the digital certificate based on the determined validity or invalidity of the digital certificate of the file and further based on a set of intermediate digital certificates in the certificate chain, wherein a low level of trust is assigned to the end certificate based on a determination that at least one intermediate digital certificate of the set of intermediate digital certificates is a digital certificate used to sign a known malicious file, wherein a medium level of trust is assigned to the end certificate based on a determination that at least one intermediate digital certificate of the set of intermediate digital certificates is a valid digital certificate, and wherein a high level of trust is assigned to the end certificate based on a determination that at least one intermediate digital certificate of the set of intermediate digital certificates being issued by a trusted certification authority; and performing an antivirus checking method on the file based on the assigned level of trust of the digital certificate of the file, wherein one or more of heuristic analysis, emulation, and blocking execution is performed on the file having a digital certificate with an assigned low level of trust.
 2. The method of claim 1, further comprising: assigning, to at least one digital certificate in the set of intermediate digital certificates in the certificate chain, a low level of trust based on invalidity of the at least one digital certificate or based on the at least one digital certificate being used to sign a known malicious file.
 3. The method of claim 1, further comprising: assigning, to at least one digital certificate in the set of intermediate digital certificates in the certificate chain, a medium level of trust based on a validity of the at least one digital certificate; and performing signature matching of the file having a digital certificate with a medium level of trust.
 4. The method of claim 1, further comprising: assigning, to at least one digital certificate in the set of intermediate digital certificates in the certificate chain, a high level of trust based on digital certificates issued by a trusted certification authority; and not performing antivirus checking of a file having a digital certificate with a high level of trust.
 5. The method of claim 1, wherein determining validity of the digital certificate includes: constructing the certificate chain associated with the certificate of the file; and traversing the certificate chain and validating each certificate in the chain.
 6. The method of claim 1, further comprising: assigning a low level of trust to the end certificate based on an intermediate certificate in the certificate chain that were found in certificate chains of a malicious file even if other certificates in the certificate chain have an assigned medium or high level of trust.
 7. The method of claim 1, wherein determining whether a digital certificate is valid when one or more of the following conditions is met: a digital signature of a certification authority associated with the digital certificate is correct; a validity period of the certificate has not expired at a present moment; and the certificate has not been revoked.
 8. A system for performing antivirus checking of a file, the system comprising: a hardware processor configured to: obtain a digital certificate of the file, wherein the digital certificate is an end certificate associated with a certificate chain; determine validity of the obtained digital certificate of the file by decrypting a digital signature of the obtained digital certificate using a public key of an intermediate certificate authority, calculating a hash value of the digital certificate, and determining a match of the decrypted digital signature with the calculated hash value; assign a level of trust to the digital certificate based on the determined validity or invalidity of the digital certificate of the file and further based on a set of intermediate digital certificates in the certificate chain, wherein a low level of trust is assigned to the end certificate based on a determination that at least one intermediate digital certificate of the set of intermediate digital certificates is a digital certificate used to sign a known malicious file, wherein a medium level of trust is assigned to the end certificate based on a determination that at least one intermediate digital certificate of the set of intermediate digital certificates is a valid digital certificate, and wherein a high level of trust is assigned to the end certificate based on a determination that at least one intermediate digital certificate of the set of intermediate digital certificates being issued by a trusted certification authority; and perform an antivirus checking method on the file based on the assigned level of trust of the digital certificate of the file, wherein one or more of heuristic analysis, emulation, and blocking execution is performed on the file having a digital certificate with an assigned low level of trust.
 9. The system of claim 8, wherein the hardware processor further configured to: assign, to at least one digital certificate in the set of intermediate digital certificates in the certificate chain, a low level of trust based on invalidity of at least one digital certificate or based on the least one digital certificate being used to sign a known malicious file.
 10. The system of claim 8, wherein the hardware processor further configured to: assign, to at least one digital certificate in the set of intermediate digital certificates in the certificate chain, a medium level of trust based on validity of the at least one digital certificate; and perform signature matching of the file having a digital certificate with a medium level of trust.
 11. The system of claim 8, wherein the hardware processor further configured to: assign, to at least one digital certificate in the set of intermediate digital certificates in the certificate chain, a high level of trust based on digital certificates issued by a trusted certification authority; and not perform antivirus checking of a file having a digital certificate with a high level of trust.
 12. The system of claim 8, wherein determining validity of the digital certificate includes: constructing the certificate chain associated with the certificate of the file; and traversing the certificate chain and validating each certificate in the chain.
 13. The system of claim 8, wherein the hardware processor further configured to: assign a low level of trust to the end certificate based on an intermediate certificate in the certificate chain that were found in certificate chains of a malicious file even if other certificates in the certificate chain have an assigned medium or high level of trust.
 14. The system of claim 8, wherein determining whether a digital certificate is valid when one or more of the following conditions is met: a digital signature of a certification authority associated with the digital certificate is correct; a validity period of the certificate has not expired at a present moment; and the certificate has not been revoked.
 15. A computer program product, stored on a non-transitory computer readable medium, wherein the computer program product includes computer executable instructions for performing antivirus checking of a file, including instructions for: obtaining a digital certificate of the file, wherein the digital certificate is an end certificate associated with a certificate chain; determining, by a hardware processor, validity of the obtained digital certificate by decrypting a digital signature of the obtained digital certificate using a public key of an intermediate certificate authority, calculating a hash value of the digital certificate, and determining a match of the decrypted digital signature with the calculated hash value; assigning a level of trust to the digital certificate based on the determined validity or invalidity of the digital certificate of the file and further based on a set of with intermediate digital certificates in the certificate chain, wherein a low level of trust is assigned to the end certificate based on a determination that at least one intermediate digital certificate of the set of intermediate digital certificates is a digital certificate used to sign a known malicious file, wherein a medium level of trust is assigned to the end certificate based on a determination that at least one intermediate digital certificate of the set of intermediate digital certificates is a valid digital certificate, and wherein a high level of trust is assigned to the end certificate based on a determination that at least one intermediate digital certificate of the set of intermediate digital certificates being issued by a trusted certification authority; and performing an antivirus checking method on the file based on the assigned level of trust of the digital certificate of the file, wherein one or more of heuristic analysis, emulation, and blocking execution is performed on the file having a digital certificate with an assigned low level of trust.
 16. The computer program product of claim 15, further comprising instructions for: assigning, to at least one digital certificate in the set of intermediate digital certificates in the certificate chain, a low level of trust based on invalidity of the at least one digital certificate or based on the at least one digital certificate being used to sign a known malicious file.
 17. The computer program product of claim 15, further comprising instructions for: assigning, to at least one digital certificate in the set of intermediate digital certificates in the certificate chain, a medium level of trust based on a validity of the at least one digital certificate; and performing signature matching of the file having a digital certificate with a medium level of trust.
 18. The computer program product of claim 15, further comprising instructions for: assigning, to at least one digital certificate in the set of intermediate digital certificates in the certificate chain, a high level of trust based on digital certificates issued by a trusted certification authority; and not performing antivirus checking of a file having a digital certificate with a high level of trust.
 19. The computer program product of claim 15, wherein instructions for determining validity of the digital certificate include instructions for: constructing the certificate chain associated with the certificate of the file; and traversing the certificate chain and validating each certificate in the chain.
 20. The computer program product of claim 15, further comprising instructions for: assigning a low level of trust to the end certificate based an intermediate certificate in the certificate chain that were found in certificate chains of a malicious file even if other certificates in the certificate chain have an assigned medium or high level of trust. 